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REMARKS/ARGUMENTS 

In light of the remarks to follow, reconsideration and allowance of this application 
are requested. 

Claims 1-2, 5-9, and 12-14 have been rejected under 35 U.S.C. § 102(e) as being 
anticipated by Apte et al. U.S. Patent No. 6,269,373 (Apte et al.) and the claims 3-4 and 
10-11 have been rejected under 35 U.S.C. § 103(a) as being unpatentable over Apte et al. 
and further in view of U.S. Published Application No. 2002/0147696 (Acker et al). 
Claims 4 and 11 have been canceled, thereby obviating the rejection of these claims. 
Applicants respectfully traverse these rejections with respect to the remaining claims. 

Applicants submit that Apte et al. and Acker et al are not prior art under 35 
U.S.C. § 102 and the § 102 and §103 rejections in Paper Nos. 5 and 8 based on Apte et al. 
and Acker et al. are improper and should be withdrawn. As stated in the Declaration filed 
on April 19, 2004, applicants respectfully submit that well prior to the February 26, 1999 
filing date of the Apte et al. patent (and well prior to the August 12, 1999 filing date of 
the Acker et al. published application), the present invention was conceived and reduced 
to practice. Both the Apte et al. patent and Acker et al. published application are 
therefore inapplicable as § 102 prior art and a reference that does not qualify as prior art 
under § 102 cannot be basis of a rejection under § 102 and §103. Applicant therefore 
respectfully request that rejections based on allegedly anticipation by Apte et al. and/or 
obviousness over the combination of Apte et al. patent and Acker et al. published 
application be reconsidered and withdrawn. 

The Examiner alleges that the evidence submitted with the Declaration is 
insufficient to establish a conception of the invention of Apte et al. Applicant 
respectfully directs the Examiner attention to Exhibit B which includes a sample source 
code for SmartHandle.java, including the java.util.Comparable interface and delegation 
to a SmartKey for comparing attributes associated with the primary key to permit two 
EJB Handles to be compared without instantiating the corresponding Entity EJB Objects. 
Accordingly, Applicants respectfully submits that the evidence submitted with 
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Declaration filed on April 19, 2004 is sufficient to establish a conception of the invention 
prior to the effective date of Apte et al. 

Moreover, contrary to the Examiner's assertion, Apte et al. independently or in 
combination with Acker et al. does not teach or suggest the present invention recited in 
claims 1 and 8. Apte et al. relates to a method for persisting a container-managed server 
object or bean in a distributed data processing system. Acker et al. relates to a system 
and method for improving name service behavior in a object-oriented programming 
environment, i.e., name service scoping behavior. Only the present invention teaches or 
suggests a SmartHandle which extends the capabilities of the EJB Handle, such as 
enabling part comparison of two EJB Handles without instantiating the actual EJB object, 
thereby advantageously enabling the present invention to order a list of SmartHandles 
without accessing the remote objects that they refer to (i.e., actual EJB objects), as 
required in amended independent claims 1 and 8. 

Contrary to the Examiner's assertion, Acker et al. does not teach or suggest 
"delegating to a SmartKey class that implements a java code to perform a field-by-field 
comparison of attributes associated with said primary key, thereby permitting two EJB 
Handles to be compared without instantiating the corresponding Entity EJB," as required 
in amended claims 1 and 8 (originally recited in canceled claims 4 and 11). In fact, 
paragraph 38 in Acker et al. cited by the Examiner, merely states that "the scoped 
CBCtxFactory 704 is the intermediate layer that provides the scoping behavior ... A 
delegation model could be just as easily be used, or the scoped initial context factory 
could completely implement the javax.naming.spi.InitialContexFactory interface." 
Applicants respectfully submit that one of ordinary skill in the art would not equate 
performing a field-by-field comparison of attributes associated with said primary key, 
thereby permitting two EJB Handles to be compared without instantiating the 
corresponding Entity EJB to Acker et al's scoped CBCtxFactory 704 or a delegation 
model to implement the javax.naming.spi.InitialContexFactory interface." That is, the 
Examiner alleges that Acker's name service scoping behavior is equivalent to performing 
a field-by-field comparison of attributes associated with said primary key, thereby 
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permitting two EJB Handles to be compared without instantiating the corresponding 
Entity EJB, as called for in amended claims 1 and 8. 

Applicants respectfully request that the Examiner indicate where in Ackers et al. it 
teaches "delegating to a SmartKey class that implements a java code to perform a field- 
by-field comparison of attributes associated with said primary key, thereby permitting 
two EJB Handles to be compared without instantiating the corresponding Entity EJB/ 5 as 
required in amended claims 1 and 8 (originally recited in canceled claims 4 and 11). 

Additionally, the Examiner incorrectly alleges that Apte et al. teaches the step of 
"maintaining an instance of a SmartKey that describes said primary key for a database 
column to which an Entity EJB object is mapped," as required in claim 1 and similarly in 
claim 8. In fact, col. 16, lines 57-65 and col. 17, lines 21-28 in Apte et al, cited by the 
Examiner, merely recite that " a container implemented on top of an RDBMS may 
manage persistence by storing each bean's data as a row in a table." Whereas the present 
invention teaches that the instance of a SmartKey that describes the primary key to be 
maintained in a database column to which an Entity EJB object is mapped. This 
advantageously allows the SmartKeys and the SmartHandles that contain them to be 
easily compared and stored in ordered lists. 

Further, the Examiner incorrectly alleges that Apte et al. teaches the step of 
"maintaining an Entity EJB object relationship thorough a combination of a proxy 
pattern, an EJB Handle, and a primary key of the EJB Handle," as required in claim 1 and 
similarly in claim 8. In fact, col. 16, lines 40-52 in Apte et al., cited by the Examiner, 
merely describes that "An entity bean can be created in two ways ..." Applicants are 
puzzled as to how "creation of an entity bean" is equivalent to "maintaining an Entity 
EJB object relationship." 

Furthermore, the Examiner incorrectly alleges that the Apte et al. teaches the step 
of "storing EJB Home class from which an Entity EJB was generated and from which 
said Entity EJB can be re-instantiated," as required in claim 1 and similarly in claim 8. In 
fact, col. 16, lines 53-56 in Apte et al., cited by the Examiner, merely recites that "the 
bean is entirely responsible for storing and retrieving its instance data." However, 
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applicants respectfully submits that one of ordinary skill in the art would not equate the 
step storing of its instance data by the bean to the step of "storing EJB Home class from 
which an Entity EJB was generated and from which said EJB can be re-instantiated," as 
called for in claim 1 (similarly in claim 8). 

Of course, a rejection based on 35 U.S.C. § 102(e) requires that the cited reference 
disclose each and every element covered by the claim. Electro Medical Systems S.A. v. 
Cooper Life Sciences Inc., 32 USPQ2d 1017, 1019 (Fed. Cir. 1994); Lewmar Marine Inc. 
v. Barientlnc, 3 USPQ2d 1766, 1767-68 (Fed. Cir. 1987), cert denied, 484 U.S. 1007 
(1988); Verdegaal Bros., Inc. v. Union Oil Co., 814 F.2d 628, 631, 2 USPQ2d 1051, 
1053 (Fed. Cir.), cert, denied, 484 U.S. 827 (1987). The Federal Circuit has mandated 
that 35 U.S.C. §102 requires no less than "complete anticipation ... [anticipation 
requires the presence in a single prior art disclosure of all elements of a claimed invention 
arranged as in the claim." Connell v. sears f Roebuck & Co., 772 F.2d 1542, 1548, 220 
USPQ 193, 198 (Fed. Cir. 1983); See also, Electro Medical Systems, 32 USPQ2d at 
1019; Verdegaal Bros., 814 F.2d at 631. 

In view of the foregoing differences, it is respectfully submitted that Apte et al. 
does not anticipate nor render obvious the invention as recited in claims 1 and 8, 
therefore, claims 1 and 8 are patentably distinct over this prior art. It is requested the 
rejection of claims 1 and 8 under 35 U.S.C. § 102(e) be withdrawn. 

Since claims 2, 5-7, 9 and 12-14 depend from claims 1 and 8, respectively, the 
foregoing discussion of claims 1 and 8 is equally applicable to claims 2, 5-7, 9 and 12-14 
and is believed to obviate the rejection of claims 2, 5-7, 9 and 12-14. 

In addition, it should be noted that claim 2 (and similarly claim 9) recites the step 
of "instantiating said Entity EJB object associated with said SmartHandle with a single 
method invocation." Apte et al. neither teaches or suggests such instantiating step. In 
fact, col. 16, lines 10-17 in Apte et al., cited by the Examiner, merely describe "stateless 
session beans" and is not even remotely related to an Entity Bean. 

Claim 5 (and similarly claim 12) defines that "said SmartKey includes said 
primary key of said EJB Handle, thereby providing portability to said Entity EJB object." 
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Apte et al. neither teaches or suggests such SmartKey. In fact, col. 8, lines 58-67 in Apte 

et al, cited by the Examiner, merely describes that Remote Method Invocation depends 
on many features of Java-object serialization, portable, downloadable object 
implementations. 

Claim 6 (and similarly claim 13) recites the step of "assigning each attribute of 
said Entity EJB object and said SmartKey to a separate column within a relational 
database table, thereby permitting the SmartHandle to be mapped to a multi-column 
relational database table." Apte et al. neither teaches or suggests such assigning step 
where each attribute of the Entity EJB object and the SmartKey are assigned to a separate 
column. In fact, col. 16, lines 57-61 in Apte et al, cited by the Examiner, merely 
describes that "a container implemented on top of an RDBMS may manage persistence 
by storing each bean's data as a row in a table." 

Claim 7 (and similarly claim 14) defines that SmartHandle includes at least 
attributes HomeClassName, KeyClassName and HomeName. Apte et al. does not teach 
or suggest such SmartHandle. 

As stated herein, Acker et al. relates to process and system for providing name 
service scoping behavior. But, Acker et al. is not suggestive of performing a field-by- 
field comparison of attributes associated with said primary key, thereby permitting two 
EJB Handles to be compared without instantiating the corresponding Entity EJB, as 
required in amended independent claims 1 and 8 Also, Acker et al. is not suggestive of 
the steps of maintaining an Entity EJB object relationship, storing EJB Home class from 
which an Entity EJB was generated and from which it can be re-instantiated, and 
maintaining an instance of a SmartKey that describes the primary key for a database 
column which an Entity EJB object is mapped, as required in claim 1 and similarly in 
claim 8. These, of course, are features recited by independent claims 1 and 8 (and thus 
are included in dependent claims 3 and 10) and not found in Apte et al. and Acker et al. 
Hence, the addition of Acker et al. does not cure the aforenoted deficiencies of Apte et al. 

In view of the foregoing differences, it is respectfully submitted that the 
combination of Apte et al. and Acker et al. does not render obvious claims 3-4 and 10-11. 

25486205.1 9 



THEOR 201.1 US (09907976^ 

The Commissioner is hereby authorized to deduct any fee or credit any 
overpayment to Deposit Accounf No. '50-0624, under Order No. NY-THEOR 201.1 
(09907976) from which the undersigned is authorized to draw. 

Respectfully submitted, 




C. Andrew Im 
Registration No.: 40,657 
FULBRIGHT & JAWORSKI L.L.P. 
666 Fifth Avenue 
New York, New York 10103 
(212) 318-3000 
(212)318-3400 (Fax) 
Attorneys for Applicant 
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